Found 8 posts.
Search results Show results as topic list.
Technical Discussion » Continue to increment point numbers after particles die
- Alex P Twigg
- 8 posts
- Offline
As far as I know you can't copy using anything other than the point number. What is it that you want to happen to the geo when the particle dies? Do you want it to die as well or do you want it to hang around?
Technical Discussion » Warning from shaders in locked digital assets
- Alex P Twigg
- 8 posts
- Offline
Sadly in most instances I need the shader to have displacement so that isn't an option usually. Sad times!
Technical Discussion » Continue to increment point numbers after particles die
- Alex P Twigg
- 8 posts
- Offline
So what you might be looking for is point ID. These aren't re-used in a particle sim. If you set the ID of the copied geo to that of the particles (you can do this on the copy sop) and change motion blur of the object to Geometry Velocity Blur this should sort you out.
The motion blur is set in the Sampling tab of the Rendering tab of the geo node you are working in.
The motion blur is set in the Sampling tab of the Rendering tab of the geo node you are working in.
Technical Discussion » Random speed for copied geos
- Alex P Twigg
- 8 posts
- Offline
A simple way to do this is with vops.
If you are copying onto points then you could put a point VOP on the points before the copy. The vop takes point ID and generates a random number from 0 to 1 and then fits this to a user specified range, such as 0.35 to 4.5, and then multiplies it by the current frame.
Take the position and set the vector component 1 to the output of the frame multiply. Add this to the unaltered position value and pipe it into the output P.
It wouldn't be too hard to do this in VEX either if you are feeling a bit codey.
Hope that helps!
Have fun
If you are copying onto points then you could put a point VOP on the points before the copy. The vop takes point ID and generates a random number from 0 to 1 and then fits this to a user specified range, such as 0.35 to 4.5, and then multiplies it by the current frame.
Take the position and set the vector component 1 to the output of the frame multiply. Add this to the unaltered position value and pipe it into the output P.
It wouldn't be too hard to do this in VEX either if you are feeling a bit codey.
Hope that helps!
Have fun
Edited by Alex P Twigg - March 1, 2017 11:46:45
Technical Discussion » Warning from shaders in locked digital assets
- Alex P Twigg
- 8 posts
- Offline
Howdy,
This isn't urgent or anything…mostly just annoying. I have created a few digital assets that contain nested shaders and in locked assets I get the following warnings on loading the hip file:
Warning: Problem while synchronizing child node:
Warning: Invalid channel “vm_displacebound” specified in parameter.
Invalide channel “vm_truedisplace” specified in parameter.
The warning doesn't occur when the node is unlocked or is saved as unlocked but does happen if all child nodes are set to editable in the HDA options and the HDA is saved as locked.
As I say, it is mostly annoying and doesn't interfere with functionality at all, but it does increase support requests when other artists use assets that pop up this error.
Anyone any thoughts?
Thanks,
Alex
This isn't urgent or anything…mostly just annoying. I have created a few digital assets that contain nested shaders and in locked assets I get the following warnings on loading the hip file:
Warning: Problem while synchronizing child node:
Warning: Invalid channel “vm_displacebound” specified in parameter.
Invalide channel “vm_truedisplace” specified in parameter.
The warning doesn't occur when the node is unlocked or is saved as unlocked but does happen if all child nodes are set to editable in the HDA options and the HDA is saved as locked.
As I say, it is mostly annoying and doesn't interfere with functionality at all, but it does increase support requests when other artists use assets that pop up this error.
Anyone any thoughts?
Thanks,
Alex
Technical Discussion » Style Sheet Processing Time
- Alex P Twigg
- 8 posts
- Offline
Hey Mark,
We are currently using 15.5.578.
The shader is simply a referenced shader in SHOPs, though it is quite a heavy custom shader so I am sure that is adding to the render time.
The operation we saw a really notable increase in processing time was when we add variation to a shader using a data binding. We took an attribute from the packed object and bound it to the primitives to add variation at render time. How does the variation work under the hood? Does it create a new instance of the shader for each variance value? If so, this could explain our heavy processing time when paired with our heavy duty shader.
Our current workflow is to assign materials using the material sop and create variation by using a render state node within the shader to bind down any attributes we need from the packed object to the primitive. The only issue with this workflow is we need to have all shading groups packed individually for it to work without the style sheets.
We are currently using 15.5.578.
The shader is simply a referenced shader in SHOPs, though it is quite a heavy custom shader so I am sure that is adding to the render time.
The operation we saw a really notable increase in processing time was when we add variation to a shader using a data binding. We took an attribute from the packed object and bound it to the primitives to add variation at render time. How does the variation work under the hood? Does it create a new instance of the shader for each variance value? If so, this could explain our heavy processing time when paired with our heavy duty shader.
Our current workflow is to assign materials using the material sop and create variation by using a render state node within the shader to bind down any attributes we need from the packed object to the primitive. The only issue with this workflow is we need to have all shading groups packed individually for it to work without the style sheets.
Technical Discussion » Style Sheet Processing Time
- Alex P Twigg
- 8 posts
- Offline
So I have been working a lot with style sheets over the last year. The setups I have been working on have been pretty large scale with tens to hundreds of thousands of objects and all shader assignments done through style sheets. As the project grew, we noticed greater and greater overheads to the shader assignments at render time so I decided to do some testing to see what is the most efficient way to work.
I used a single test object of 56,375 polys with three groups used for shader assignment. This was then brought in as a packed disk primitive and the style sheets applied. The three styles were structured as follows:
Target: Primitive
Sub-Target: Primitive
Condition: Primitive Group
Override: Set Material
With this setup the style sheet took 11 seconds to process. Not huge really, but I then started duplicating the object to replicate a more real world situation. Below are the results:
So at lower numbers the overhead isn't too bad, but as the number increases the overheads start to be greater than the actual render times.
I then tried changing the setup by caching out each group of geo and bringing them in as 3 packed disks and then merging. The style sheets were modified as follows:
Target: Primitive
Condition: Primitive Group
Override: Set Material
The processing times were as follows:
So there is a reduction in time, but this is still pretty high for what is still a limited scene. Things got crazy slow when I started creating variance per shader using style sheets and it was deemed just too slow to be a viable method.
Has anyone else using style sheets experienced these kind of overheads? The studio I work in had planned to use style sheets as a core of their look pipeline, but if I am not doing anything drastically wrong I am not sure this is a method we should pursue.
I used a single test object of 56,375 polys with three groups used for shader assignment. This was then brought in as a packed disk primitive and the style sheets applied. The three styles were structured as follows:
Target: Primitive
Sub-Target: Primitive
Condition: Primitive Group
Override: Set Material
With this setup the style sheet took 11 seconds to process. Not huge really, but I then started duplicating the object to replicate a more real world situation. Below are the results:
- 100 Duplicates: 18 seconds
250 Duplicates: 33 seconds
500 Duplicates: 55 seconds
1000 Duplicates: 121 seconds
2500 Duplicates: 249 seconds
5000 Duplicates: 740 seconds
So at lower numbers the overhead isn't too bad, but as the number increases the overheads start to be greater than the actual render times.
I then tried changing the setup by caching out each group of geo and bringing them in as 3 packed disks and then merging. The style sheets were modified as follows:
Target: Primitive
Condition: Primitive Group
Override: Set Material
The processing times were as follows:
- 1 Duplicate: 8 seconds
100 Duplicates: 12 seconds
250 Duplicates: 22 seconds
500 Duplicates: 38 seconds
1000 Duplicates: 75 seconds
2500 Duplicates: 185 seconds
5000 Duplicates: 361 seconds
So there is a reduction in time, but this is still pretty high for what is still a limited scene. Things got crazy slow when I started creating variance per shader using style sheets and it was deemed just too slow to be a viable method.
Has anyone else using style sheets experienced these kind of overheads? The studio I work in had planned to use style sheets as a core of their look pipeline, but if I am not doing anything drastically wrong I am not sure this is a method we should pursue.
Houdini Engine for Maya » Using python to interact with an OTL
- Alex P Twigg
- 8 posts
- Offline
Howdy all,
I am currently working on some pipeline tools and am using Houdini engine in Maya to prep geo for export and later use in Houdini. The OTL is simply adding a rest attribute and creating some groups…all very simple.
The problem I am running into is that the only way I have figure out to kick off the alembic rop in the otl is to promote the render button to the top level and to activate it with a maya.cmds.setAttr() call.
This does fire off the render, but the script doesn't hold while the geo writes as the button returns as pressed immediately. This results in the script continuing to run while the geo is being written, so the script gets to the cleanup stage before the write is complete. This deletes the engine node in Maya and results in a failed or broken alembic.
Ideally I would like a way to directly access the alembic rop and push a call such as alembic_rop.render().
Any thoughts?
I am currently working on some pipeline tools and am using Houdini engine in Maya to prep geo for export and later use in Houdini. The OTL is simply adding a rest attribute and creating some groups…all very simple.
The problem I am running into is that the only way I have figure out to kick off the alembic rop in the otl is to promote the render button to the top level and to activate it with a maya.cmds.setAttr() call.
This does fire off the render, but the script doesn't hold while the geo writes as the button returns as pressed immediately. This results in the script continuing to run while the geo is being written, so the script gets to the cleanup stage before the write is complete. This deletes the engine node in Maya and results in a failed or broken alembic.
Ideally I would like a way to directly access the alembic rop and push a call such as alembic_rop.render().
Any thoughts?
-
- Quick Links